Some comments from Claude Code (could be complete slop, I know little about Rust):

General

1. Panic-Driven Error Handling is Unacceptable
The validation system at src/rowbinary/validation.rs:68-82 uses panic! for schema mismatches. This is fundamentally wrong in a library:

• Library rule # 1: Never panic on user input
• Creates unrecoverable failures for recoverable errors
• Violates Rust's error handling principles
• Makes debugging extremely difficult in production

Recommendation: Convert all panic! calls to proper Result<T, ValidationError> returns.

2. API Breaking Changes Without Semver

• Query::fetch() now uses RowBinaryWithNamesAndTypes instead of RowBinary (line 90 in query.rs)
• RowCursor::new() signature changed to require ValidationMode
• This changes wire protocol - breaking change disguised as feature addition

Performance optimizations

🔥 High-Impact Optimizations

1. Eliminate Allocations in Error Paths

Location: src/rowbinary/validation.rs:46-51

// Current: Allocates strings in panic paths
format!("{}.{}", self.get_struct_name(), c.name)
"Struct".to_string()

// Better: Use Cow<str> for zero-allocation error messages
use std::borrow::Cow;
fn get_current_column_name(&self) -> Cow<'static, str> {
    // avoid format! allocation
}

2. Optimize String Deserialization

Location: src/rowbinary/de.rs:67, 184

// Current: Always allocates Vec for String
fn read_vec(&mut self, size: usize) -> Result<Vec<u8>> {
    Ok(self.read_slice(size)?.to_vec())  // ❌ Always allocates
}

// Better: Only allocate when necessary
fn deserialize_string<V: Visitor<'data>>(self, visitor: V) -> Result<V::Value> {
    let slice = self.read_slice(size)?;
    match str::from_utf8(slice) {
        Ok(s) => visitor.visit_borrowed_str(s),  // Zero-copy!
        Err(_) => {
            let string = String::from_utf8_lossy(slice).into_owned();
            visitor.visit_string(string)  // Only allocate for invalid UTF-8
        }
    }
}

3. Branch Prediction Optimization in Validation

Location: src/cursors/row.rs:96-104

// Current: Pattern matching on validation count
let (result, not_enough_data) = match self.rows_to_validate {
    0 => rowbinary::deserialize_from::<T>(&mut slice, &[]),
    u64::MAX => rowbinary::deserialize_from::<T>(&mut slice, &self.columns),
    _ => { /* ... */ }
};

// Better: Likely/unlikely hints for branch predictor
let (result, not_enough_data) = if likely(self.rows_to_validate > 0) {
    if self.rows_to_validate == u64::MAX {
        rowbinary::deserialize_from::<T>(&mut slice, &self.columns)
    } else {
        self.rows_to_validate -= 1;
        rowbinary::deserialize_from::<T>(&mut slice, &self.columns)
    }
} else {
    rowbinary::deserialize_from::<T>(&mut slice, &[])
};

🎯 Medium-Impact Optimizations

4. Validation State Caching

Location: src/rowbinary/validation.rs:87-90

// Current: Validates every field access
self.validator.validate(serde_type)?;

// Better: Cache validation results for repeated patterns
struct CachedValidator {
    last_column_idx: usize,
    last_validation: Option<ValidatedState>,
}

5. SIMD-Optimized Size Checks

Location: src/rowbinary/de.rs:89

// Current: Individual size checks
ensure_size(&mut self.input, core::mem::size_of::<$ty>())?;

// Better: Batch size checks for multiple fields
fn ensure_sizes_batch(input: &[u8], sizes: &[usize]) -> Result<()> {
    // SIMD-optimized batch boundary checking
}

6. Avoid Repeated Column Lookups

Location: src/rowbinary/validation.rs:42-52

// Current: String formatting on every error
format!("{}.{}", self.get_struct_name(), c.name)

// Better: Pre-format common error prefixes
struct ErrorContext {
    column_prefix: String,  // Pre-computed once per struct
}

@ilidemi, thanks. Here are some comments on that:

1. Panic-Driven Error Handling is Unacceptable

It is more than acceptable here. It panics in case of an invalid struct definition in the code, there is no reason to continue (de)serializing junk. It is unsafe, and Rust guidelines explicitly say the following about trying to continue with incorrect values:

The panic! macro signals that your program is in a state it can’t handle and lets you tell the process to stop instead of trying to proceed with invalid or incorrect values.

I get that we have exactly this situation. See the explanation about the Result:

The Result enum uses Rust’s type system to indicate that operations might fail in a way that your code could recover from.

It is not possible to recover a program that uses the crate from an incorrect struct definition. It must be fixed by the user.

2. API Breaking Changes Without Semver
   Query::fetch() now uses RowBinaryWithNamesAndTypes instead of RowBinary (line 90 in query.rs)
   RowCursor::new() signature changed to require ValidationMode
   This changes wire protocol - breaking change disguised as feature addition

Well, RBWNAT instead of RB is the intention. It will also go as 0.14.0, where breaking changes are actually allowed. RowCursor is private to the end user, it's visibility is pub(crate), so it does not matter.

2. Optimize String Deserialization

Worth looking into.

3. Branch Prediction Optimization in Validation

Hints are unstable, and we cannot use them. But RowCursor became ~20% slower, that is a fact, and ideally we need to find a way to reduce the overhead, but I couldn't yet.

4. Validation State Caching

It already validates only one array value and one key-value pair of a Map.

5. SIMD-Optimized Size Checks

Worth checking indeed.

1. Eliminate Allocations in Error Paths

6. Avoid Repeated Column Lookups

There are no errors, only panics, so does not really matter IMO.

25% hit rate, definitely space for improvement 😊

Got a few more from Opus 4:

1. On panic vs Result - database could be migrated from underneath the app (or all apps updated but one). The app wouldn't be able to access the data anyway, but there's a difference between failing one path and crashing the process.
2. ensure_size could be #[inline(always)], although the compiler would likely figure it out
3. Save on runtime branches for validation on every row by using static generics to distinguish fast path from slow path. Although it agreed that the branch predictor would likely catch on when they stop being taken many times in a row.